extends ../templates/main.jade

block title
  | Python | Language Criticism | xigoi

block content
  h1 Python Language Criticism
  p I like Python. It's a very easy to use language with clean syntax and a rich library system. However, there are several things I don't exactly like about it, which I'm going to cover here.
  h2 General Characteristics
  ul
    li Python is dynamically typed. That used to be a great thing, but now that most statically typed languages have type inference, dynamic typing has pretty much only drawbacks. Yes, there are type annotations and MyPy, but you can't always rely on them, especially if using a library that doesn't have annotations.
  h2 Language Features
  ul
    li There are no enums, instead strings are used for their purpose, which is slow and error-prone.
    li Why are decorators limited to functions and classes? They would be useful for other things.
  h2 Syntax
  ul
    li Anonymous functions require a long keyword (which would sometimes be useful as a variable name) and they're restricted to a single expression. Note that, contrary to popular belief, this limitation is not a consequence of indentation-based syntax: CoffeeScript and Nim, which are both indentation-based, manage to have multiple-statement anonymous functions just fine.
    li The syntax for conditional expressions has the condition in the middle, which looks jumbled up.
    li In comprehensions, 
      code for
      |  loops are written in reverse order than normal (first inner, then outer).
    li The distinction between statements and expressions is quite unnecessary. See Ruby as an example of a language which is similar to Python, but takes the “everything is an expression” approach.
    li The set of operators is limited, with no way to define new ones.
    li “Dunder” methods are incredibly ugly. Even C++ has better syntax for constructors and operator overloading.
    li There's no syntax for documentation comments, but instead… string literals???
    li It uses up valuable characters for bitwise operators, which are very rarely needed in high-level programming. Especially 
      code ^
      |  would be useful for exponentiation. Bitwise operators could very well be functions tucked away in a standard library module.
  h2 Built-ins & Standard library
  ul
    li The language is really inconsistent about what is a function and what is a method. For example, 
      code lst.sort()
      | , but 
      code sorted(lst)
      | . And some of these functions actually just call a method with the same name, but surrounded in double underscores! What's the point of that? Why not just directly make it a method?
    li The 
      code unittest
      |  module uses 
      code camelCase
      |  identifiers, even though the language convention is 
      code snake_case
      | . How does something like this even happen? Did nobody catch this in the review? If they even have a review process?
      p
        a(href="https://stackoverflow.com/questions/17014763/why-are-unittest2-methods-camelcase-if-names-with-underscores-are-preferred") According to StackOverflow
        | , it's based on some old Smalltalk library. I get that copying a good library from another language is often a good idea, but did it have to be so verbatim that it won't even adapt to the language's most basic conventions?
  h2 Tooling
  ul
    li Installation management is 
      a(href="https://xkcd.com/1987/") an absolute chaos
      | .
